home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 15707 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.3 KB
  1. Path: aloha.com!jching
  2. From: jching@aloha.com (Jimen Ching)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: COLLEGE PROFESSORS! #
  5. Date: 21 Apr 1996 08:48:47 GMT
  6. Organization: Coconut Wireless
  7. Distribution: world
  8. Message-ID: <4lcspf$cq7@news.aloha.com>
  9. References: <Pine.A32.3.91.960417134130.26474G-100000@red.weeg.uiowa.edu <8BEE4D1.02C700325C.uuout@sourcebbs.com>
  10. NNTP-Posting-Host: mango.aloha.com
  11. X-Newsreader: TIN [version 1.2 PL2]
  12.  
  13. DAVID MOHORN (david.mohorn@sourcebbs.com) wrote:
  14. >I agree.  There are times when writing such code that readability is
  15. >more important than efficiency, but the logic of this code was
  16. >illogical, verified data that was already identified as being invalid,
  17. >so why continue scanning the data...  I think a construct such as:
  18.  
  19. If it means anything, I agree with you.  I think the example your
  20. professor provided was not the best to use.  Though I too consider
  21. readability to be very important.  I also believe that you can have
  22. your cake and each it too.  I.e. your code could be both readable and
  23. efficient.
  24.  
  25. [ code example deleted ]
  26.  
  27. My first rule of programming is "Never say never."  Such rules as:
  28.     Never use goto's
  29.     Never have multiple exit points
  30.     Never nest if statements
  31.  
  32. I simply don't understand why people have such rules.  The rule should
  33. be "Know when to use..., and when not to..."
  34.  
  35. You've already showed the 'multiple exit points'.  If you don't like
  36. that, here are a few alternatives, using the other *nevers*.
  37.  
  38. Status = "GOOD"
  39. if (A) goto ErrorExitPoint
  40. else process_data
  41.  
  42. if (B) goto ErrorExitPoint
  43. else process_data
  44.  
  45. if (C) goto ErrorExitPoint
  46. else process_data
  47. goto ExitPoint
  48.  
  49. ErrorExitPoint:
  50. Status = "BAD"
  51.  
  52. ExitPoint:
  53. return Status
  54.  
  55. If you don't like goto's (use nested if's)...
  56.  
  57. Status = "GOOD"
  58. if (not A) then
  59.   process_data
  60.   if (not B) then
  61.     process_data
  62.     if (not C) then
  63.       process_data
  64.     else
  65.       Status = "BAD"
  66.     endif
  67.   else
  68.     Status = "BAD"
  69.   endif
  70. else
  71.   Status = "BAD"
  72. endif
  73. return Status
  74.  
  75. And if you don't like nested if's...
  76.  
  77. Status="GOOD"
  78. if (not A) then
  79.     Status = process_data_and_test_B_and_C (B, C)
  80. else
  81.     Status = "BAD"
  82. return Status
  83.  
  84. process_data_and_test_B_and_C (B, C)
  85. Status = "GOOD"
  86. process_data
  87. if (not B) then
  88.     Status = process_data_and_test_C (C)
  89. else
  90.     Status = "BAD"
  91. endif
  92. return Status
  93.  
  94. process_data_and_test_C (C)
  95. Status = "GOOD"
  96. process_data
  97. if (not C)
  98.     process_data
  99. else
  100.     Status = "BAD"
  101. endif
  102. return Status
  103.  
  104. This implementation does not use goto's, does not have multiple exit
  105. points, and does not use nested if statements.  It is also very easy to
  106. read.  Not only that, it is also modular.
  107.  
  108. > I retorted his remark and said it would on a multitasking system where
  109. > every cycle counts!  If I were validating 10,000 data items, example 1
  110. > would take a considerable amount of time longer than example 2!
  111.  
  112. First of all.  This little example is not a good candidate for measuring
  113. performance.  I.e.  example 2 is only faster if the first condition is
  114. true for a large amount of iterations.  If all test conditions were false
  115. (i.e. process_data is called every time), there would be no difference.
  116. Even if you used some random distribution for the test conditions,
  117. the performance might not matter much if process_data is taking most
  118. of the time.  To be a good software engineer (I'm assuming you're not
  119. a simple programmer), you must consider the situation very carefully
  120. and select your optimization points that give you the most benefit.
  121. But, if this is the most inner loop of your program.  Then saving two
  122. extra comparisons could mean a significant performance boost.  Especially
  123. in RISC systems that do not have good branch prediction hardware.  I
  124. don't have numbers to back me up, but I have tested one program where
  125. a simple loop killed the entire program (made it slow as hell).
  126.  
  127. >RN>  In this day and age of Alphas, Pentiums, PowerPCs, MIPSs, and home
  128. >  >computers with 24MB of interleaved DIMM RAM, which multitasking systems are
  129. >  >those?  Do you honestly believe that Windows code squeezes out every
  130. >  >microsecond?
  131.  
  132. So are you saying if people don't have a PowerPC and 24MB of ram, that
  133. they can't run any software?  When a piece of software is a hog, it's
  134. a hog no matter what hardware you have.
  135.  
  136. >RN>  My horror story is one word long:  BASIC.
  137. >I disagree.
  138.  
  139. You obviously haven't read other peoples BASIC code.  ;-)
  140. --jc
  141. --
  142. Jimen Ching (WH6BRR)      jching@aloha.com     wh6brr@uhm.ampr.org
  143.